CRC class implementation #5911

deepikabhavnani · 2018-01-24T05:05:16Z

Alternate CRC implementation to #5669.

CRC class MbedCRC.h is templated class created to support hardware/software CRCs. Default CRC will be hardware CRC when support for HAL is available.

Polynomial tables are available for 8/16 bit CCITT, 7/16 bit for SD card and 32-bit ANSI. Polynomial table implementation will be used if Hardware CRC is not available.

In case device does not have hardware CRC and polynomial table is not supported, CRC is still available and is computed runtime bit by bit for all data input.

Here is the example for new implementation. https://gist.github.com/deepikabhavnani/44737819d512c86de49ceeabf8867ef7

Default constructor without any arguments is valid only for supported CRC polynomials.
MbedCRC<POLY_7BIT_SD, 7> ct; --- Valid
MbedCRC<0x07, 7> ct; --- Valid
MbedCRC<0x07, 7> ct(a,b,c,d) -- Valid - Note: Though inital/final/.... values are different, they do not affect the table hence ROM table will be used.
MbedCRC<0x7, 8> ct; --- Invalid, compilation error
If a user passed non supported polynomial, then it will give compilation error same as we have in call backs.

For non-supported polynomials, user need to provide other constructor args as well.
MbedCRC<0x7, 8> ct(a, b, c, d); -- Valid - Note we do not have ROM table for non-supported polynomials, hence it will be either HW or Bitwise.

0xc0170

What are differences between these 2 implementations ? Why would I choose this one instead of the earlier one? +/- ?

0xc0170 · 2018-01-24T09:44:59Z

drivers/TableCRC.h

+/** \addtogroup drivers */
+/** @{*/
+
+extern const uint8_t _Table_CRC_7Bit_SD[];


global symbol like this starting with _ ? I would just leave it without

@0xc0170 It is prohibited to have an identifier name starting by a single underscore and followed by an uppercase letter. These are reserved for the C and C++ library implementation and compiler intrinsic (_Bool is an example).

0xc0170 · 2018-01-24T09:48:05Z

drivers/MbedCRC.h

+#define MBED_CRC_API_H
+
+#include <stdint.h>
+#include <TableCRC.h>


"TableCRC.h"

0xc0170 · 2018-01-24T09:48:23Z

drivers/MbedCRC.h

+ */
+ MbedCRC(uint32_t intial_xor, uint32_t final_xor, bool reflect_data, bool reflect_remainder);
+ MbedCRC();
+ virtual ~MbedCRC() {


{ new line

pan-

@deepikabhavnani Good submission, I have few questions:

Could you detail how hardware CRC will be supported and how it fit with the MbedCRC template class ?
I'm not sure to understand the polymorphic model of MbedCRC, compute is virtual but init, deinit and all the partial computations aren't. Could you explain how MbedCRC should be used in polymorphic context and how it should be subclassed ?
The member variables if MbedCRC are set at initialization not mutated afterwards. Is there a reason why these variables are not const (or part of the template list) ?

I've also noticed that most code can be completely extracted out of the class (as plain old functions). It may be interesting to extract it to avoid code bloat.

pan- · 2018-01-24T10:13:39Z

drivers/MbedCRC.c

+
+#if DEVICE_CRC
+
+namespace mbed {


namespace is not a valid C keyword. Is it a C file or a C++ one ?

pan- · 2018-01-24T10:23:02Z

drivers/TableCRC.h

+/** \addtogroup drivers */
+/** @{*/
+
+extern const uint8_t _Table_CRC_7Bit_SD[];


@0xc0170 It is prohibited to have an identifier name starting by a single underscore and followed by an uppercase letter. These are reserved for the C and C++ library implementation and compiler intrinsic (_Bool is an example).

pan- · 2018-01-24T10:33:03Z

drivers/MbedCRC.h

+
+/* Default values for different types of polynomials
+*/
+template <uint32_t polynomial, uint8_t width> MbedCRC<polynomial, width>::MbedCRC(uint32_t intial_xor, uint32_t final_xor, bool reflect_data, bool reflect_remainder):


Could you split into two lines the template parameter list and the function signature ?

pan- · 2018-01-24T10:39:17Z

drivers/MbedCRC.h

+ }
+
+private:
+ uint8_t _width;


Are you sure that _polynomial and _width are required ? They are already part of the template definition.

pan- · 2018-01-24T10:43:19Z

drivers/MbedCRC.h

+ * @param data final crc value
+ * @return Reflected CRC value
+ */
+ uint32_t reflect_remainder(uint32_t data)


This function can be marked as const.

pan- · 2018-01-24T10:49:28Z

drivers/MbedCRC.h

+ * @param crc CRC value is filled in, but the value is not the final
+ * @return 0 on success or a negative error code on failure
+ */
+ int32_t bitwise_compute_partial(void *buffer, crc_data_size_t size, uint32_t *crc)


This function can be marked as const. buffer can be const.

pan- · 2018-01-24T10:51:45Z

drivers/MbedCRC.h

+ MBED_ASSERT(crc != NULL);
+ MBED_ASSERT(buffer != NULL);
+
+ uint8_t *data = static_cast<uint8_t *>(buffer);


pan- · 2018-01-24T10:53:29Z

drivers/MbedCRC.h

+ * @return 0 on success or a negative error code on failure
+ */
+
+ int32_t table_compute_partial(void *buffer, crc_data_size_t size, uint32_t *crc)


This function can be marked as const. buffer can be const.

pan- · 2018-01-24T10:55:14Z

drivers/MbedCRC.h

+*/
+template <uint32_t polynomial, uint8_t width> MbedCRC<polynomial, width>::MbedCRC(uint32_t intial_xor, uint32_t final_xor, bool reflect_data, bool reflect_remainder):
+ _inital_value(intial_xor), _final_xor(final_xor), _reflect_data(reflect_data), _reflect_remainder(reflect_remainder)
+{


Could you initialize the class member in the constructor initialization list ?

pan- · 2018-01-24T10:58:41Z

drivers/MbedCRC.h

+ * @param reflect_data
+ * @param reflect_remainder
+ */
+ MbedCRC(uint32_t intial_xor, uint32_t final_xor, bool reflect_data, bool reflect_remainder);


Typo: intial_xor

deepikabhavnani · 2018-01-24T15:55:03Z

What are differences between these 2 implementations ? Why would I choose this one instead of the earlier one? +/- ?

Previous implementation had multiple classes, and support for different CRC techniques, all of which were not required. According to @sg- it will be good to have HW as default and Table based if HW does not support. Bitwise only when HW and ROM table is not present in code. Also, he suggested to have single template class and no inheritance as it was confusing and usage was not that good.

First implementation can support all techniques, but little confusing for user. Second one is user friendly with basic functionality. Adding support of other techniques like HalfByteCRC will be difficult in new implementation, but on other hand HAL / HW support will be easy.

deepikabhavnani · 2018-01-24T15:55:11Z

Could you detail how hardware CRC will be supported and how it fit with the MbedCRC template class ?

For hardware crc, HAL should have API to check polynomial supported by specific target. In constructor, same API will be used to check is if polynomial is supported by hardware, and set the private bool member "_isHW" accordingly. In rest of the member functions, decision will be based on private member "isHW" and HAL functions will be added with proper locking.

MbedCRC.c file was added for HAL, it is not required at present (missed to remove it :-( )

deepikabhavnani · 2018-01-24T15:57:03Z

I'm not sure to understand the polymorphic model of MbedCRC, compute is virtual but init, deinit and all the partial computations aren't. Could you explain how MbedCRC should be used in polymorphic context and how it should be subclassed ?

Sorry for the confusion, none of the member functions should be virtual (I missed to remove). We will have single class to support CRC and no-inheritance. Hope this answers your query.

deepikabhavnani · 2018-01-24T15:58:49Z

The member variables if MbedCRC are set at initialization not mutated afterwards. Is there a reason why these variables are not const (or part of the template list) ?

I am not sure if I understood this question properly, can you help me understand which member variable you are taking about?

pan- · 2018-01-24T16:11:00Z

Whoops I should have read my sentences before submitting them.

Member variables of the MbedCRC class are set at construction time and never modified in member functions. Therefore these variable are good candidates for const qualification. By extension it should be possible to transform these variables into template parameters but this may be overkill.

deepikabhavnani · 2018-01-24T16:52:43Z

@pan- Agree all variables (passed to constructor) are constant and set once. But using them as part of template will not be user friendly and we will have hell lot of combinations for specialization case where we use ROM tables.

CRC class `MbedCRC.h` is templated class created to support hardware/software CRCs. Default CRC will be hardware CRC when support for HAL is available. Polynomial tables are available for 8/16 bit CCITT, 7/16 bit for SD card and 32-bit ANSI. Polynomial table implementation will be used if Hardware CRC is not available. In case device does not have hardware CRC and polynomial table is not supported, CRC is still available and is computed runtime bit by bit for all data input.

pan- · 2018-01-25T11:59:49Z

drivers/MbedCRC.h

+ */
+ MbedCRC(uint32_t initial_xor, uint32_t final_xor, bool reflect_data, bool reflect_remainder);
+ MbedCRC();
+ virtual ~MbedCRC()


Please remove the virtual specifier if the class is not meant to be used in a polymorphic way.

All the driver files have destructor and mutex as virtual functions, was not sure why so tried to be consistent with that. With HW implementation, mutex will be required.

Thanks for the clarification; it makes more sense if the class embeds lock/unlock functions that can be overridden.

pan- · 2018-01-25T12:00:56Z

drivers/MbedCRC.h

+ *
+ * @return 0 on success or a negative error code on failure
+ */
+ int32_t init(void)


I suppose this will do something when hardware CRC will be available. Is it a correct assumption ?

I'm not sure about that, it's an interface, I wouldn't like people to use it:

MbedCRC crc(...); crc.init(); crc.compute(...); crc.deinit();

Can't we just use constructor/destructor for (de)init code?

pan- · 2018-01-25T15:09:35Z

drivers/MbedCRC.h

+ */
+ void mbed_crc_ctor(void) const
+ {
+ MBED_STATIC_ASSERT(width <= 32, "Max 32-bit CRC supported");


You can use MBED_STATIC_ASSERT at the class scope. It is not necessary to wrap it into a specific function called in the constructor.

I left it intentionally over there, so that we have common constructor function, where hardware CRC check and other HW CRC related stuff can be done else I will have to keep empty function. Can we move it when we add support for Hardware?

bulislaw

Looks great! Could you share your thoughts on how to integrate HW CRC into this?

bulislaw · 2018-02-01T15:15:44Z

drivers/MbedCRC.h

+
+ /** Lifetime of CRC object
+ *
+ * @param initial_xor Inital value/seed to Xor (Default ~0x0)


There's no default parameter for the initial_xor and final_xor so saying here that default is ~0x0 is confusing.

bulislaw · 2018-02-01T15:16:15Z

drivers/MbedCRC.h

+ POLY_32BIT_ANSI = 0x04C11DB7, // x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1
+} crc_polynomial_t;
+
+/** CRC object provides CRC generation through hardware/software


Could we get some short example of the usage here for both compute and partial? Also could we get some worlds about algorithm used (ignoring hw for now).

bulislaw · 2018-02-01T15:19:27Z

drivers/MbedCRC.h

+ *
+ * @return 0 on success or a negative error code on failure
+ */
+ int32_t init(void)


I'm not sure about that, it's an interface, I wouldn't like people to use it:

MbedCRC crc(...); crc.init(); crc.compute(...); crc.deinit();

Can't we just use constructor/destructor for (de)init code?

bulislaw · 2018-02-01T15:21:30Z

drivers/MbedCRC.h

+ */
+ int32_t compute(void *buffer, crc_data_size_t size, uint32_t *crc)
+ {
+ int32_t status;


Should we assert on crc being null?

bulislaw · 2018-02-01T15:22:55Z

drivers/MbedCRC.h

+ int32_t compute_partial(void *buffer, crc_data_size_t size, uint32_t *crc)
+ {
+ if (NULL == _crc_table) {
+ // Compute Slow CRC


is that official name of the algorithm? If not can we not use slow as it sounds bad.

bulislaw · 2018-02-01T15:26:46Z

drivers/MbedCRC.h

+
+#if defined ( __CC_ARM )
+#elif defined ( __GNUC__ )
+#pragma GCC diagnostic pop


Can we add a comment about what does it do?

I am disabling warnings reported as "Shift count is negative", which is kind of invalid warning.

".\mbed-os\drivers/MbedCRC.h(231): warning: #62-D: shift count is negative
detected during instantiation of "std::int32_t mbed::MbedCRC<polynomial, width>::compute_partial_stop(std::uint32_t *) [with polynomial=79764919U, width=(std::uint8_t)' ']" at line 15 of "main.cpp""

Code

if ((width < 8) && (NULL == _crc_table)) { p_crc = (uint32_t)(p_crc << (8 - width)); }

Compiler warns of the shift operation with width as it is width=(std::uint8_t), but we check for ( width < 8) before performing shift, so it should not be an issue.

Do we add such detailed information in code?

If you just add one sentence description, it will save combined hours of googling over couple of years ;)

Oh that's switching it off... ignore me

deepikabhavnani · 2018-02-01T15:45:49Z

@bulislaw

Looks great! Could you share your thoughts on how to integrate HW CRC into this?

For hardware crc, HAL should have API to check polynomial supported by specific target. In constructor, same API will be used to check is if polynomial is supported by hardware, and set the private bool member "_isHW" accordingly. In rest of the member functions, decision will be based on private member "isHW" and HAL functions will be added with proper locking.

Can't we just use constructor/destructor for (de)init code?

We can use constructor/destructor for software CRC as there is no failure case during initialization. But in case of hardware, initialization in init will help in case of failures and will be consistent with other drivers.

pan- · 2018-02-01T16:53:50Z

drivers/TableCRC.h

+/** \addtogroup drivers */
+/** @{*/
+
+const uint8_t Table_CRC_7Bit_SD[] = {


All definitions should go into a cpp file.

pan- · 2018-02-01T16:56:57Z

drivers/MbedCRC.h

+#define MBED_CRC_API_H
+
+#include <stdint.h>
+#include "drivers/TableCRC.h"


mbed_assert.h header is missing.

bulislaw · 2018-02-05T12:23:11Z

how does this relates to #5669 ? Should we try to unify it (aka close one)?

deepikabhavnani · 2018-02-07T05:08:39Z

@bulislaw #5669 is closed, and review comments are addressed.

@sg- Please review

MikeDK · 2018-02-07T11:30:46Z

If I'm allowed to make one comment...: I think the crc table should be #ifdef'ed with a macro which tells the compiler if the current target has hw crc support ... Or else this table will just waste flash space when it is not used due to hw crc capability. (for example add 'CRC' to the 'device_has'-parts in the targets/targets.json file, which will result in a preprocessor macro "DEVICE_CRC")

This should be done as soon as the HAL is specified and implemented.

Template specialized functions are moved to cpp file, to add MbedCRC.h in mbed.h. Else linker shall multiple definition error.

deepikabhavnani · 2018-02-20T18:34:36Z

/morph build

mbed-ci · 2018-02-20T18:52:41Z

Build : SUCCESS

Build number : 1191
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5911/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

mbed-ci · 2018-02-20T20:27:03Z

Exporter Build : SUCCESS

Build number : 865
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5911/

mbed-ci · 2018-02-20T21:03:43Z

Test : SUCCESS

Build number : 991
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5911/991

0xc0170 · 2018-02-21T10:32:03Z

@bulislaw Can you review after changes?

Three-week old review is stale, and no updated comments in two weeks. Re-review requested.

cmonr · 2018-02-23T02:56:44Z

Holding off on merging this PR to wait for @bulislaw's and @SenRamakri's reviews. Not critical for 5.7.6, but will likely need to be completed by End of Next Week.

0xc0170 · 2018-02-26T13:36:03Z

drivers/TableCRC.cpp

+ 0x220, 0x8225, 0x822f, 0x22a, 0x823b, 0x23e, 0x234, 0x8231, 0x8213, 0x216, 0x21c, 0x8219
+};
+
+uint32_t Table_CRC_32bit_ANSI[256] = {


Looking at these tables in this code file, they need to reside in RAM (we change them - I could find that we use them for calculations but never store anything in these) ?

Looking at these tables in this code file, they need to reside in RAM

Tables were moved to ROM section from RAM after discussion with @sg- @pan- and @geky

I could find that we use them for calculations but never store anything in these

Yes, they are read-only.

In order to be stored in ROM I believe they need to also be marked const. The compiler doesn't know if they could be modified otherwise.

0xc0170 · 2018-02-26T13:38:25Z

drivers/MbedCRC.h

+#include "drivers/TableCRC.h"
+#include "platform/mbed_assert.h"
+
+#if defined ( __CC_ARM )


Cant find a reference for these lines here. why push/pop is gere for GCC and that negative shift warning ignored.

I am disabling warnings reported as "Shift count is negative", which is kind of invalid warning.
Warning is from below code section.
https://github.com/ARMmbed/mbed-os/pull/5911/files/af0982295f010f3dd45ade36ddc9155a5f86289e#diff-a353a07f9612be80e818a21f61ec8409R210

if ((width < 8) && (NULL == _crc_table)) { p_crc = (uint32_t)(p_crc << (8 - width)); }

Compiler warns of the shift operation with width as it is width=(std::uint8_t), but we check for ( width < 8) before performing shift, so it should not be an issue.

That is useful to know, please leave either in the code short description or commit message.

0xc0170 · 2018-02-26T13:40:00Z

drivers/MbedCRC.h

+ */
+ uint32_t get_crc_mask(void) const
+ {
+ return (width < 8 ? ((1u << 8)-1) : (uint32_t)((uint64_t)(1ull << width) - 1));


((1u << 8)-1) spaces around -

0xc0170 · 2018-02-27T14:48:35Z

drivers/TableCRC.cpp

@@ -107,7 +107,7 @@ uint16_t Table_CRC_16bit_IBM[256] = {
 0x220, 0x8225, 0x822f, 0x22a, 0x823b, 0x23e, 0x234, 0x8231, 0x8213, 0x216, 0x21c, 0x8219
 };

-uint32_t Table_CRC_32bit_ANSI[256] = {
+extern const uint32_t Table_CRC_32bit_ANSI[256] = {


extern is useless here as it's definition, external linkage by default .

One question related, you have sizes in definition and declaration. You could set these to a macro, or a declaration does not need the size, thus if t his changes, no need to change the declaration.
Declaration can be: extern const uint32_t Table_CRC_32bit_ANSI[];.

external linkage is default in C, but with C++ if array constant is inside the namespace default linkage is internal.
I will replace 256 to a macro, but will keep the size in declaration as well.

deepikabhavnani · 2018-02-28T14:52:15Z

/morph build

deepikabhavnani · 2018-02-28T14:52:45Z

@0xc0170 - Please review the changes, and let me know if your comments are not addressed properly

mbed-ci · 2018-02-28T15:38:18Z

Build : SUCCESS

Build number : 1296
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5911/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

mbed-ci · 2018-02-28T16:38:17Z

Exporter Build : SUCCESS

Build number : 957
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5911/

mbed-ci · 2018-02-28T17:34:37Z

Test : SUCCESS

Build number : 1082
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5911/1082

cmonr

Approving since it looks like this PR has addressed all outdated comments.

SenRamakri

Approved

SenRamakri · 2018-02-28T18:15:57Z

drivers/MbedCRC.cpp

+*/
+template <uint32_t polynomial, uint8_t width>
+MbedCRC<polynomial, width>::MbedCRC(uint32_t initial_xor, uint32_t final_xor, bool reflect_data, bool reflect_remainder):
+ _initial_value(initial_xor), _final_xor(final_xor), _reflect_data(reflect_data), _reflect_remainder(reflect_remainder), _crc_table(NULL)


Add line break before _crc_table to align with other declarations style.

deepikabhavnani force-pushed the common_crc branch 2 times, most recently from 801650e to ec16b02 Compare January 24, 2018 05:10

0xc0170 added the needs: review label Jan 24, 2018

0xc0170 reviewed Jan 24, 2018

View reviewed changes

pan- reviewed Jan 24, 2018

View reviewed changes

deepikabhavnani force-pushed the common_crc branch from ec16b02 to 23a5c21 Compare January 24, 2018 18:14

deepikabhavnani force-pushed the common_crc branch from 23a5c21 to afe8834 Compare January 24, 2018 19:26

pan- reviewed Jan 25, 2018

View reviewed changes

deepikabhavnani requested review from bulislaw and sg- January 27, 2018 23:03

bulislaw previously requested changes Feb 1, 2018

View reviewed changes

pan- reviewed Feb 1, 2018

View reviewed changes

drivers/MbedCRC.h

#define MBED_CRC_API_H

#include <stdint.h>

#include "drivers/TableCRC.h"

Copy link

Member

pan- Feb 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mbed_assert.h header is missing.

deepikabhavnani force-pushed the common_crc branch from 6fbf725 to 013b09c Compare February 1, 2018 18:25

Removed init/deinit and added cpp file for tables

8e53711

deepikabhavnani force-pushed the common_crc branch from 013b09c to 8e53711 Compare February 2, 2018 15:43

deepikabhavnani mentioned this pull request Feb 5, 2018

CRC feature implementation #5669

Closed

Moved specialized functions to CPP file

af09822

Template specialized functions are moved to cpp file, to add MbedCRC.h in mbed.h. Else linker shall multiple definition error.

deepikabhavnani force-pushed the common_crc branch from c7d18a0 to af09822 Compare February 20, 2018 14:12

0xc0170 requested a review from SenRamakri February 21, 2018 10:13

cmonr added the ready for merge label Feb 22, 2018

cmonr removed the ready for merge label Feb 23, 2018

bulislaw previously approved these changes Feb 26, 2018

View reviewed changes

0xc0170 reviewed Feb 26, 2018

View reviewed changes

deepikabhavnani dismissed bulislaw’s stale review via 3910f1f February 26, 2018 17:00

0xc0170 reviewed Feb 27, 2018

View reviewed changes

Updated table to be const and small fixes

b60eb1d

deepikabhavnani force-pushed the common_crc branch from 3910f1f to b60eb1d Compare February 27, 2018 15:44

cmonr approved these changes Feb 28, 2018

View reviewed changes

cmonr merged commit 3d1174a into ARMmbed:master Feb 28, 2018

cmonr added release-version: 5.8.0-rc1 and removed needs: review labels Feb 28, 2018

deepikabhavnani deleted the common_crc branch February 28, 2018 18:07

SenRamakri reviewed Feb 28, 2018

View reviewed changes

daniel-cesarini-tridonic-com mentioned this pull request Apr 5, 2018

CRC Thread safety #6546

Closed

CRC class implementation #5911

CRC class implementation #5911

Conversation

deepikabhavnani commented Jan 24, 2018 • edited Loading

0xc0170 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pan- left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deepikabhavnani commented Jan 24, 2018

deepikabhavnani commented Jan 24, 2018

deepikabhavnani commented Jan 24, 2018

deepikabhavnani commented Jan 24, 2018

pan- commented Jan 24, 2018 • edited Loading

deepikabhavnani commented Jan 24, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deepikabhavnani Jan 25, 2018 • edited Loading

Choose a reason for hiding this comment

bulislaw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deepikabhavnani Feb 1, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deepikabhavnani commented Feb 1, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bulislaw commented Feb 5, 2018

deepikabhavnani commented Feb 7, 2018

MikeDK commented Feb 7, 2018 • edited Loading

deepikabhavnani commented Feb 20, 2018

mbed-ci commented Feb 20, 2018

Triggering tests

mbed-ci commented Feb 20, 2018

mbed-ci commented Feb 20, 2018

0xc0170 commented Feb 21, 2018

cmonr commented Feb 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xc0170 Feb 27, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deepikabhavnani commented Feb 28, 2018

deepikabhavnani commented Feb 28, 2018

mbed-ci commented Feb 28, 2018

Triggering tests

mbed-ci commented Feb 28, 2018

mbed-ci commented Feb 28, 2018

cmonr left a comment

Choose a reason for hiding this comment

deepikabhavnani commented Jan 24, 2018 •

edited

Loading

pan- commented Jan 24, 2018 •

edited

Loading

deepikabhavnani Jan 25, 2018 •

edited

Loading

deepikabhavnani Feb 1, 2018 •

edited

Loading

MikeDK commented Feb 7, 2018 •

edited

Loading

0xc0170 Feb 27, 2018 •

edited

Loading